home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000027_owner-urn-ietf _Thu Jan 30 14:15:15 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA08988 for urn-ietf-out; Thu, 30 Jan 1997 14:15:15 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA08983 for <urn-ietf@services.bunyip.com>; Thu, 30 Jan 1997 14:15:13 -0500
  3. Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA15858  (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 14:15:11 -0500
  5. Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id NAA06349; Thu, 30 Jan 1997 13:14:59 -0600 (CST)
  6. From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  7. Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id NAA28043; Thu, 30 Jan 1997 13:15:16 -0600 (CST)
  8. Date: Thu, 30 Jan 1997 13:15:16 -0600 (CST)
  9. Message-Id: <199701301915.NAA28043@void.ncsa.uiuc.edu>
  10. To: David Durand <dgd@cs.bu.edu>
  11. Cc: urn-ietf@bunyip.com
  12. Subject: Re: [URN] Some good ideas coming out of the "relative..."  discussions...
  13. In-Reply-To: <199701301711.MAA19220@csb.bu.edu>
  14. References: <199701301711.MAA19220@csb.bu.edu>
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. David Durand writes:
  21.  > ... Now, if we have to encode FPIs to
  22.  > make them into URNs that is OK, but if the relative URN stuff comes
  23.  > out, it will make sense to unescape the slashes again. So there will
  24.  > be two canonical representations for the same URN, depending on  when
  25.  > it was issued, kind of defeating the goals of persistence.
  26.  
  27. Allowing multiple names for things does not defeat the persistence or
  28. uniqueness properties.  The persistence property is that the name is
  29. never used again for anything else.  The uniqueness property is that a
  30. name is only the name of one resource (which may be a mutable
  31. resource) not that the resource only has one name.
  32.  
  33.  > ... If we make no special allowances now,
  34.  > and later decide that we really need relative URNs we could add
  35.  > another kind of resolution service that takes a base URN and a
  36.  > relative URN and returns the "real" URN.
  37.  
  38. This service is call concatenation.  Clients can do it themselves.
  39.  
  40. dan